A “transaction” is a familiar concept to most people. A common example of a transaction is buying groceries: a consumer puts one or more items in a cart, takes the cart to the checkout register, and pays for the items. If the consumer fails to carry out any of these “operations,” such as taking the cart to the checkout register, then the whole transaction fails. This example is analogous to online shopping as well: a consumer browses a website for books, puts one or more books in a virtual cart, clicks the “buy” button, and pays for the books. Both examples can be distilled or expanded to include additional operations, such as a bank debiting the consumer's account as part of the payment operation, or the online merchant updating inventory after the consumer pays. In general terms, though, a “transaction” can be, and often is, characterized as an individual unit of work comprised of several operations. See Sanjay Mahapatra, Transaction Management under J2EE 1.2, JavaWorld, at http://www.javaworld.com (July 2000), incorporated herein by reference. Naturally, computers have come to play a large role in implementing transaction processing. Using computers to manage transactions, though, requires substantial programming efforts at varying levels, which include the business operations level and the data processing levels.
While neither the concept of a “transaction” nor the use of computers to implement transaction processing is new, the methods used to implement such transaction processing has seen rapid change in recent years. In particular, advances in client/server and object-oriented technologies have changed transaction processing significantly.
In recent years the traditional two-tier client/server system has been slowly displaced by more sophisticated multi-tier client/server systems. In general, a multi-tier system places at least one intermediate component between the client and the server. These components are referred to commonly as “middleware.” Generalized “n-tier” systems include n layers of software that provide a different layer of services at varying levels of detail to the layers above and beneath them, where n is any number. See Mark Johnson, A beginner's guide to Enterprise JavaBeans, JavaWorld, at http://www.javaworld.com (October 1998), incorporated herein by reference. Programmers often use multiple client/server tiers in transactional processing to separate and delegate the programming tasks required for managing a transaction. In particular, one tier usually includes objects that implement the business operations while one or more other tiers provide objects that implement the underlying data processing (such as creating a data structure to represent the cart or saving the consumer's order to a database).
“Object-oriented” languages and techniques also have become increasingly popular in recent years. In general, an “object” is a named memory unit that contains data and instructions for manipulating that data. In an object-oriented context, the term “attribute” or “property” generally refers to the data within the memory unit, and the term “method” or “procedure” refers to the related instructions for manipulating the data. In practice, objects often include methods that direct the process of storing the object's attributes within a file or database. Of course, an object that includes such a method also generally includes one or more methods that direct other types of operations, such as updating or removing attributes from the file or database. In transactional processing, then, objects can represent the attributes of physical entities within the transaction (such as a grocery item or book), as well as implement the business operations in any given transaction (such as putting a grocery item or book in a cart).
Today, computer programmers frequently implement transaction processing with a mix of n-tiered architectures and object-oriented technology. Sun Microsystems, Inc. (SUN) has developed a comprehensive collection of objects and other supporting programs that programmers can use to build sophisticated transaction processing systems. SUN markets this collection as the JAVA 2 ENTERPRISE EDITION (J2EE) platform. SUN also has developed an application program interface (API) for J2EE that defines an n-tiered architecture, which SUN markets as the ENTERPRISE JAVABEANS (EJB) architecture.
Generally, an EJB architecture comprises an EJB server, an EJB container, an EJB component (also commonly known as a “bean), an EJB object, and a database. An EJB component, which typically implements business operations, executes within an EJB container. EJB components also must have a “home interface” through which an EJB object can create, initialize, remove, and find a specific instance of an EJB component. The methods that a home object implements to find a specific instance of an EJB component and retrieve data are known as “finder” methods. The EJB container, which implements many of the data processing operations, executes within an EJB server. According to SUN's specification, an EJB container also must be able to manage transactions. The EJB server generally executes within any given computer's native environment. An EJB object, though, allows client programs to execute the EJB component, through the EJB component's EJB container. FIG. 1 depicts a typical EJB system architecture. Generally, each of these EJB subsystems comprises one or more objects that implement the functions of the interface. Thus, the term “EJB client” will be used herein, instead of the term “EJB object,” to avoid any confusion with a generic “object.”
An “entity bean” is one type of EJB component used to model data in business transactions, the attributes of which are typically stored within a database. The term “persist” generally refers to the process of storing, updating, and deleting such attributes to or from a database. An entity bean may manage the persistence of its attributes, or it may delegate the responsibility to the EJB container in which it executes. An EJB client may explicitly request the entity bean, or the EJB container, to persist the entity bean's attributes. Alternatively, the entity bean or EJB container, as the case may be, may persist the attributes when there is a need, such as occurs when a second EJB client needs to access the attributes in the database.
A “session bean” is another type of EJB component. A session bean is used to manage a single client application's use of other EJB components. Like an entity bean, a session bean generally has attributes, but a session bean's attributes usually are not persisted to a database. A session bean may or may not participate in transactions.
Persons skilled in the art will appreciate that any operation that accesses a database consumes at least some quantity of available computing resources, thereby decreasing the resources available for other computing tasks. Thus, a computer program that frequently operates on attributes within a database can decrease computer performance significantly. Likewise, a computer program that operates on a database indirectly through one or more objects, such as an entity bean or container, can cause the same performance reduction. Consequently, programmers often store requested database operations in a temporary location, commonly referred to as a “cache,” in order to minimize the number of database operations and improve a program's overall performance.
While the concept of “caching” operations is not new, there is much room for improvement in the implementation of caching mechanisms. For example, Gopalan Suresh Raj, Enterprise JavaBeans, Web Cornucopia, at http://members.tripod.com/gsraj/ejb (last updated Dec. 19, 1998), incorporated herein by reference, discloses a session bean that implements a simple caching mechanism. A session bean, however, usually is customized for a particular client application. Furthermore, many session beans are not designed to handle transaction processing.
Thus, the invention disclosed herein addresses the need in the art for a uniform caching mechanism that can manage transactions while minimizing the number of database operations required for any given client program. Particularly, this invention seeks to minimize the number of times that a computer program accesses a database to operate on an object's attributes stored therein.
These and other objects of the invention will be apparent to those skilled in the art from the following detailed description of a preferred embodiment of the invention.